\section{Manipulating Architectural Models}
\label{sec:architecture}

Using our framework, developers just need to write a MOF meta-model to define the architecture style, and the framework can generate the proper architecture adapter from this meta-model. Through this generated adapter, the synchronization engine can automatically manipulate the architecture models stored as XMI files, according to the defined architecture style.

It is natural to define an architecture style as a MOF meta-model. An architecture style defines what kinds of elements may exists in an architectural model (usually, but not necessarily, some kinds of components and connectors), the properties of each kind of elements, and the probable relationship between model elements. Users can use MOF classes, attributes and associations to define the the element types, properties and relationships, respectively. An example can be found in Figure~\ref{fig:metamodels}, where we use a MOF meta-model to define an architecture style imitating C2. 

Currently, we do not restrict the ways for defining ``constraints'' in an architecture style, and users can choose some mature model-driven techniques like OCL. Note that to support architecture-based runtime management, researchers have tried to add dynamic features, like update operations, into architecture styles \cite{Oreizy08}. In our approach, developers do not need to specially define such dynamic features, and we support the standard model modification like changing attribute, adding elements, etc. by default.

In our framework, we reuse a MOF implementation named Eclipse Modeling Framework (EMF) \cite{EMF} to automatically construct an architecture adapter from the meta-model
\footnote{Strictly speaking, EMF is not an implementation of MOF, because its meta-modeling language (named Ecore) is not strictly comply with MOF standard. But many model-driven technologies on MOF have corresponding implementations on Ecore, and thus, in this paper, we ignore the difference, and simply regard Ecore meta models as MOF meta-models}. 
From the meta-model, EMF can generate a set of Java classese, and these classes implement the standard MOF reflection interface. 
With the help of an XMI parser implemented by EMF, models stored as XMI files can be reified as a set of Java objects under those generated classes. 
The generated classes and the reused XMI parser forms an architecture adapter. 
The synchronization engine can automatically manipulate the models represented as Java objects through the standard interface, and the XMI parser ensure that these modifications have effects on the XMI files.






